System and method for facilitating delivery and return service

ABSTRACT

A system and method for facilitating delivery and return service between a delivery party and a receiving party. These parties may or may not have pre-registered to use the locker system. The system has locker modules ( 35 ) and a system controller ( 10 ). The system controller ( 10 ) interfaces with the locker modules ( 35 ) via a network ( 30 ). Each of the locker modules ( 35 ) has locker units for depositing and retrieving the goods and a locker controller coupled to control the locker units. Together, the system controller ( 10 ) and the locker controller enable steps of the method by processing a user input that is received via a user input interface coupled to the system controller ( 10 ) and the locker controller. The user input is associated with the receiving party and provided by the delivery party. Thereafter, the system controller ( 10 ) generates a notification message having an identification code for transmitting to the receiving party.

FIELD OF THE INVENTION

The present invention relates generally to the field of goods delivery,returns and storage systems, and in particular, to a locker system andmethod for facilitating delivery and return of transported goods such asparcels, laundry, grocery and personal items.

BACKGROUND OF THE INVENTION

It is a well known fact that the pace of modern day life is fast andoften leaves people with no time to shop, collect their deliveries, dotheir laundry, or simply meet one another to hand over personal items.This has led many people to turn to services that give them more timeand convenience. One of the services that are increasingly popular isthe ordering of goods to be delivered to the user's place of residence.These days, all types of goods can be ordered and delivered. Forinstance, many department stores have catalogues where virtually everyitem sold in the stores can be ordered by mail. Even businesses thattraditionally did not previously make regular deliveries such as thegroceries or laundries are now offering a delivery service. People arealso turning to personal concierge services to perform errands such asdelivery, returns or pick up items for them during their working hourssimply because they do not have the time.

Although the convenience of having an item delivered to a desiredlocation as opposed to traveling to the place where that item is sold isdesirable, receiving the item can be a problem. This is because someonehas to be physically present at the desired location to receive the itemand this may not be possible for some people in various situations. Forexample, home occupants that are not at home during office hours arelikely to find delivery or pickup of items at such hours inconvenient oruncomfortable to use. Hence, the delivery of goods in existing deliveryand pickup systems can be improved to accommodate such situations. (Theterms ‘pickup’ and ‘returns’ are used interchangeably.)

Most existing delivery and pickup systems focus solutions to the aboveproblem by using of one or more electronically-controlled lockers tofacilitate the delivery and pickup of goods. These lockers are placedeither outside homes or at common areas serving more than one apartmentblock where there is high human traffic. In some cases, these lockersare stand-alone systems that serve only specific merchants or users. Insome of these systems, the lockers are communicatively linked to acentral controller that is shared by a variety of merchants and users.Notification messages are transmitted to the receiving party to informthem of the need to pick up their deliveries.

Common among most existing delivery and pickup systems is the need foreither a delivery party or a receiving party or both parties to beregistered with the central controller prior to using such systems. Forexample, in U.S. Pat. No. 5,774,053 Porter, codes associated with avendor, a delivery person and a customer have to be stored in a storagedevice prior to delivery and pickup in which these codes are required.In U.S. Pat. No. 5,774,053 Porter, both the vendor and the customer mustfirst be registered with a central controller so that their respectivecodes are made available to the storage device. In thetransaction-oriented electronic accommodation system described in U.S.Pat. No. 6,116,506 Matsumoto et al and U.S. Pat. No. 6,230,971 Matsumotoet al, both assigned to Hitachi Ltd., all users or addressees must beregistered with the system before deliveries can be made. Also, onlyregistered or authorized vendors or delivery persons can make deliveriesor perform pickups from storage devices of the system. Access to thesystem is done using access codes or personal identification numbers(PIN) assigned when they are registered with the system.

Registration of vendors, delivery agents and their delivery persons mayseem to be an insignificant procedure. However, for large companies withmany delivery persons making many different deliveries each day, thiscan be quite challenging. For example, a post office may have severalthousand postmen making deliveries and every one of them have to beregistered with a unique code. In U.S. Pat. No. 5,774,053, the codeshave to be stored in the storage device. Although only codes fordelivery persons who cover the area of the storage device need to bestored, high turnover of delivery persons and frequent changing ofdelivery routes makes the administration of such codes complex andtedious.

For the systems described above, registration of users is ideal but notalways practical. Users who receive deliveries or make returns regularlygenerally find it easy to remember their codes or PINs to makecollections. However, in most cases, users tend to receive deliveriesonce in a while. While these users may register to use a system for thefirst time, such users may forget their codes or PINs the next time theywant to use the system. A user in such a situation generally does notuse the system or may register again by creating another account.Duplication of registration details is not desirable because the systemthen has to create and maintain accounts that may not be used more thanonce and that then become what are known as “dead accounts”. In mostcases, during registration, users would also provide the system withinformation on how they can be notified when there is an item or goodsto be picked up. This can be in the form of an email address or a mobilephone number. However, managing such information is troublesome,especially when users change their email addresses or mobile phonenumbers.

In the systems described above, the assumption is that both the deliveryparty and the receiving party are aware of and want to use such systemsfor deliveries. A user normally initiates this by indicating a deliveryto be made to a specified storage device. Instructions are then recordedin a delivery note so that a delivery person knows that the delivery isto be made to the storage device. However, in delivering goods to peoplewho are not at home and are not registered to use such systems, adelivery person has to make at least one more trip to complete adelivery even if storage devices of such systems are located nearby. Inthis case, the delivery person is unable to take advantage of suchsystems due to a lack of information such as, for example, whether aperson is registered to use a system and particulars of that person.

In most existing delivery and pickup systems, some Identification card(IC Card) is used as a credentialing means at a storage device. Whilethis is widely accepted, it creates a problem when the IC card is lost,spoilt or cancelled. For example, when a user decides to cancel a creditcard registered for use in a delivery and pickup system, he then has toregister a cancellation of the credit card with the system and provideinformation for a replacement card. This can be a tedious process thatis undesirable.

Although many existing delivery and pickup systems have been developed,such systems do not adequately address the above problems. Therefore,what is needed is a delivery and pickup system that keeps track of alltransactions and transacted parties, reports status of thesetransactions and intelligently keeps payment data relating to thetransactions. Such a system should also be reliable, safe and convenientto use. Furthermore, the delivery and pickup system should preferablynot require user registration or users to have prior knowledge of thesystem. In addition, the delivery and pickup system should be able toprovide all relevant parties automated notification of a delivery in aconvenient manner. Such a delivery and pickup system is currently notavailable.

BRIEF DESCRIPTION OF THE DRAWINGS

A preferred embodiment of the present invention is more fully described,by way of example, with reference to the drawings of which:

FIG. 1 is a block diagram of a locker system in accordance with thepresent invention;

FIG. 2 illustrates the physical layout of a locker module of the lockersystem of FIG. 1;

FIG. 3 is a schematic block diagram illustrating circuitry components ofthe locker module of FIG. 2;

FIG. 4 shows relationships between parties involved in transactionsusing the locker system of FIG. 1;

FIG. 5A and FIG. 5B are simplified flow diagrams illustrating the stepsfor registering a corporate user and delivery persons of the lockersystem of FIG. 1;

FIGS. 6A to 6D are simplified flow diagrams illustrating the steps forfacilitating a delivery transaction under different delivery scenarioswithin the locker system of FIG. 1;

FIG. 7A and FIG. 7B are simplified flow diagrams illustrating the stepsfor facilitating a good returns transaction under different pickupscenarios within the locker system of FIG. 1;

FIG. 8 is a flow diagram illustrating the steps for reserving via theInternet a locker unit of the locker system of FIG. 1; and

FIG. 9 is a block diagram showing an Automated Notification MessageSending System of the locker system of FIG. 1.

DETAILED DESCRIPTION OF THE DRAWINGS

In general, the present invention provides a locker system and methodsfor facilitating a delivery or return of goods in the locker system byproviding a temporary transfer facility where the delivery or returnoccurs. The transfer facility is placed at locations convenient to auser to pick up the goods. In most instances, such locations are athigh-density residential areas such as an apartment complex, thoughother high human traffic areas such as a train stations, communitycentres and post offices are also possible. The transfer facility canalso be located outside a merchant's premises, so as to allow 24-hourseven days a week collection access for their users. In this case, thetransfer facility can be licensed for the merchant's sole use.

An advantage that the invention provides over existing delivery andpickup systems is that the transfer facility for goods is available forboth registered and non-registered users of the locker system. Hence,any user can use the locker system without the need for pre-registrationor signing up for a subscription service. This is useful as in manycases; the request for a delivery or return of goods is usually fortransactions done on impulse and the need for registration may deterpotential users of such a system.

Another advantage of the invention is that notification messages aresent via common notification mean to parties of transactions who havegoods to be delivered to them to thereby inform them to pick up thegoods. This is done through notification identifiers normally providedby the parties at the time when a delivery or pickup is required. Aunique identification code such as, for example, a personalidentification number (PIN) is provided for each notification for pickupor delivery. This eliminates the need for parties to remember anidentification code, which they may not use that frequently. While someexisting delivery and pickup systems send a notification message tousers informing them that a delivery has occurred, such systemstypically requires the users to pre-register and to provide theircontact details and identification codes.

A further advantage of the invention is that a delivery person candeliver a good using the transfer facility and a receiving party cancollect the good from the transfer facility even if the receiving partydid not provide any notification details to the delivery person.

The present invention also provides a system controller to manage anetwork of such transfer facilities. The system controller functionsinclude automatic sending of notification messages, lease management,registration and management of users, logging of alarms, exceptions andtransactions, online transactions and management of accounts forindividual parties.

The operation of the locker system, in its most basic form, involves adelivery party and a receiving party. The delivery party is the partythat wishes to make a goods transfer to a receiving party. The receivingparty is the party that is willing to accept the delivery from thedelivery party. However, more than two parties may be involved in atransfer of goods. In some cases, the delivery party and the receivingparty can be one and the same.

Typically, in a delivery scenario, the parties would include a customer,a vendor, and a delivery agent communicatively coupled to the systemcontroller. For such a delivery scenario, the customer is a purchaser ofa good, the vendor is the seller of the good and the delivery agent isan entity that is responsible for delivering the good. The systemcontroller in this delivery scenario facilitates the transactionsassociated with delivery of the good. The delivery party in thisdelivery scenario comprise both the vendor and the delivery agent, whilethe receiving party is the customer.

In another delivery scenario, there could be just two individuals whereone individual wants to make a personal delivery to the otherindividual. In this delivery scenario, the individual making thepersonal delivery is the delivery party and the individual accepting thedelivery is the receiving party.

Typically, in a pickup scenario, the parties would include a customer, avendor, and a pickup agent communicatively coupled to the systemcontroller. The customer is the person who wants to make a return of agood and the vendor is the recipient of the good. The pickup agent isthe entity responsible for picking up the good. In this pickup scenario,the system controller is the party who facilitates the transactions forthe pickup to occur. For such a pickup scenario, the delivery party isthe customer, while the receiving party comprises both the vendor andthe pickup agent.

Although in general the parties are separate and independent, in somesituations, a party can take on multiple identities. For instance, in adelivery scenario, a large seller of goods may be both a vendor and adelivery agent with facilities for delivery of the goods. Also, oneparty may comprise multiple entities. For instance, a delivery agent mayhave many delivery persons, each of whom is registered with the systemcontroller. The concept can also be extended to an individual customerwho wishes to make use of the transfer facility for his own use.Accordingly, the individual customer represents both the delivery partyand the receiving party.

In the preferred embodiment of the locker system, the transfer facilityis one or more intelligent computer-controlled electronic locker modulesthat provide selective access to appropriate parties. These lockermodules are remotely connected via any available communication means toa system controller either wirelessly or wired. Each of the lockermodules can receive and send out signals to communicate with the systemcontroller. The customer, the vendor and the delivery agent can alsointeract with the system controller via some communication network suchas, for example, the Internet. Via an Internet linkage, the parties canhandle various transactions such as registration, leasing, checking ofstatus, etc. The system controller also provides notification messagesto the customer, the vendor or the delivery agent using an automatednotification system. The automated notification system informs theappropriate parties of a delivery that has been made or the need for apickup of goods. The notification messages could be transmitted viaemail, mobile phone or pager using short message service (SMS) systems,Internet web pages, Interactive Voice Response (IVR) systems, instantmessaging or any other common notification means.

The preferred embodiment of the invention can include the use of storesor collection centres utilizing a computer system that emulatesfacilities at the locker module. The preferred embodiment of the presentinvention utilizes the concept of leasing where a party wishing to use alocker unit for delivery or returns leases the locker unit for a fixedshort-term duration until the delivery or the pickup is made.

FIG. 1 is a block diagram of a locker system in accordance with thepreferred embodiment of the present invention. The locker systemcomprises a system controller 10 and locker modules 35 that aredispersed throughout a particular region. The system controller 10 isremotely and communicably (either via a wired line or a wirelesschannel) linked up with the locker modules 35. Each locker module 35contains at least one locker unit and can both receive and send outsignals to communicate with the system controller 10 through a network30. The system controller 10 is also communicably linked tocommunication devices that are respectively associated with parties thatinclude a customer 21, a vendor 22, and a delivery and pickup agent 23.In the locker system, the system controller 10 is linked to thecommunication devices via the Internet 20 so that the parties can accessa website that is associated with the system controller 10. Via theInternet 20, these parties can handle various transactions such asregistration, leasing, checking of status, etc. In this case, a userinput interface for the parties is their computers that are connected tothe Internet. The user input interface can also be provided at a lockermodule 35.

The system controller 10 also provides an automated notification messagesending system 14 that sends notification messages to a user. In thepreferred embodiment, this is done via the Short Message Service (SMS)network through the customer's mobile phone or pager.

However, it is clear that other types of network linkages between thevarious parties and the system controller 10 and notification devicesare clearly possible.

FIG. 1 also illustrates the components of the system controller 10 thatincludes an application server 11 containing all the programs forcontrolling the transfer facility system and a database 12 that storesdata. Some data is stored in the database 12 of the system controller 10while some data is stored in an embedded database of the lockercontroller PC depending on its use. The data stored in the embeddeddatabase is periodically backed up to the system controller's database12. The application server 11 is linked to a modem 13 that is linked toa public network such that the application server 11 is able tocommunicate with a locker module (54 of FIG. 3) having the anappropriate modem (54 of FIG. 3). The modems or any other communicationapparatus can be configured to provide for both wired and wirelesscommunication. The application server 11 is also linked to an automatednotification sending system 14 such that notification messages, like SMSmessages, can be sent automatically to the customer 21. Lastly, theapplication server 11 is connected to the Internet 20 so that customers21, vendors 22, delivery agents 23, and the like, can access the systemcontrollers web site.

FIG. 2 illustrates the physical layout of the locker module and FIG. 3illustrates the schematic block diagram of the circuitry for the lockermodule 41. First referring to FIG. 2, the locker module 41 generally hasa frame 42 and a plurality of locker units 46 with heavy-duty securitydoors that are numbered for easy reference. Each of the doors has alocking mechanism, which is controlled by the locker module's lockercontroller. The locker module 41 also comes with a user input interfaceand this could be a device such as a computer monitor 43 and a keypad 45and a card slot 44. Other devices could include bar code readers, RadioFrequency Identifier (RFID) readers and wireless communication (e.g.Bluetooth, Infra-Red Data Port IrDA). In the preferred embodiment, thecard slot 44 is adapted to receive smart cards, but can alternatively bemade to receive other types of cards such as credit cards, debit cards,etc. Enclosed within the walls of the locker module 41 is the circuitryfor controlling the operation of the locker module (shown in FIG. 3).The locker modules may optionally carry a camera for recording an imageof a person using the locker module.

FIG. 3 illustrates in a schematic block diagram, the circuitry forcontrolling the operation of the locker module, which includes a maincontroller PC, which is basically a computer apparatus, which will bethe locker controller 50 for handling the logical functions of thelocker module. The locker controller 50 has an embedded database that iscapable of storing data relating to a transaction. The locker controller50 is linked to a smart card reader 52 and motorised card acceptor 51for accepting and reading smart cards. The smart card reader 52 coulddouble up as a payment device if the smart card serves as an electronicwallet as well.

The locker controller 50 is also linked to a wireless or land wiredmodem 54, which can send and receive signals. Although various wirelessor wired communication technology such as SMS (short messaging service),paging, radio frequency signals may be employed, in the preferredembodiment, wired ISDN lines or cabled lines are used for wiredcommunications while a wireless modem which employs a proprietary RFtechnology is used for wireless communications. Of course, the use ofeach type of communication medium would require a switch or router thatis appropriate for the type of communication line being used and isdependent on the location of such locker modules.

Still referring to FIG. 3, the locker controller 50 is further linked toa controller card 55 which interfaces the locker controller 50 with thekeypad 58, left and right momentary switches 61 and 62, respectively,and a monitor screen 60. The keypad 58, and the left and right momentaryswitches 61 and 62 are basically other devices to provide more userinput interface for the locker module and the monitor 60 is for displayof user information and instructions. The locker controller 50 isfurther linked to the locking mechanism 57 via the controller card 55and power relays bank 56 which provide interfacing between thecontroller PC 50 and the locking mechanism 57 such that the lockercontroller 50 has full control to lock and unlock the locking mechanism57 of each locker unit. An uninterruptible power supply (UPS) 53 isoptionally connected to the locker controller 50. Also, in the preferredembodiment an LCD monitor screen 60, a keypad 58 and left and rightmomentary switches 61 and 62 are used. The monitor 60 could be a liquidcrystal display (LCD) with keypad 58, left and right momentary switches61 and 62; or a touch screen LCD monitor.

Although a specific implementation is shown in FIG. 3, it should beunderstood that this implementation is illustrative only, and does notrepresent the only way the present locker module may be implemented. Forinstance, although in the preferred embodiment for the vendor, thedelivery agent and the delivery persons, a smart card system is used, itshould be understood that other types of credentialing method or devicethat can uniquely identify an individual are possible. A smart card is arelatively recent device, which is a plastic card with a microchip. As astandard, each smart card is associated with a unique serial number,which is extracted by the locker system. By associating a smart card anda pin number (identification code) to an individual, the smart card isable to uniquely identify a person. Similarly, other identificationsystems such as fingerprint recognition systems that can uniquelyidentify an individual may be used as an alternative to the smart cardsystem. Such other identification systems just need to associate anotification identifier with a pin number or identification code. Thenotification identifier could be the mobile phone or pager number or aunique reference number that is assigned by the locker system. The smartcard can be used for payment as well with the addition of theappropriate payment devices. Other forms of payment devices could alsobe introduced, for example, contactless card with electronic wallets.

Although the preferred embodiment as shown in FIG. 1 and FIG. 3 showsthat the system controller and locker controller are two separatesystems, it is not inconceivable for the system controller and lockercontroller to be combined into a single controller. In this case, thelocker module may operate as a stand-alone system.

To more clearly illustrate the operation of the present invention, it isuseful to define the role of each party and its relationship to the roleplayed by another party.

FIG. 4 illustrates the several roles that are typical in a deliverysystem. As indicated earlier, the operation of this locker system in itsmost basic form involves a delivery party 800 and a receiving party 900,where the delivery party 800 is the one who drops off the good using thetransfer facility and the receiving party 900 is the one who collectsthe good from the transfer facility. However, in the real world wheredelivery of goods takes place, normally either the delivery party 800 orreceiving party 900 could comprise one or more different sub-roles.

The role of a delivery party can be further divided to include that of aleaseholder 70, and a delivery agent 74. The customer 72 plays the roleof a receiving party 900. A system controller 80 interfaces with theseroles.

In a typical delivery and pickup scenario, a vendor is the leaseholder70, the customer 72 is an end-user, and a third-party delivery/pickupagent 74 is a transporter of the goods. The most important of the roles,in a sense, is that of the leaseholder. The leaseholder 70 is the partywho leases a unit in the locker module. In the preferred embodiment,either the vendor or the delivery/pickup agent can play the role of theleaseholder 70, though typically, the vendor will be the leaseholder 70.In this case, the leaseholder 70 who is the vendor, has leased a lockerunit from the system controller 80 hence the leaseholder has a directrelationship with the system controller 80. The leaseholder 70 also hasa direct relationship with the customer 72 as it has sold goods to him.The leaseholder 70 further has a direct relationship with the deliveryagent 74 as the vendor has hired the delivery/pickup agent 74 to makethe delivery of the purchased good to the leased locker unit or collecta returns from the leased locker unit. Therefore, in a typical deliveryscenario, the leaseholder 70 and the delivery agent 74 is the deliveryparty while the customer 72 is the receiving party.

A variation of a typical delivery scenario would involve an individual(delivery party) who wishes to make a delivery to the end user(receiving party). Referring to FIG. 4, the delivery party is theleaseholder 70 as well as the delivery agent 74 (the transporter of thegoods), and the receiving party 72 is the end user. In the preferredembodiment, the delivery party individual plays the role of theleaseholder 70 as well as delivery agent 74. The delivery party hasleased a locker unit from the system controller 80 hence it has a directrelationship with the system controller 80. The leaseholder 70 also hasa direct relationship with the receiving party (the end user 72) as itwishes to deliver something to him. The leaseholder 70 further has adirect relationship with the delivery agent 74 as he is also playing therole of a delivery agent 74, making the delivery of the good to theleased locker unit.

The role of the system controller 80 always remains the same—as thefacilitator of the transactions. Some of the system controller's mainduties are shown in FIG. 4. Among others, the system controller 80facilitates the registration all of the parties onto its system. Itfacilitates the leasing of the locker unit to the leaseholder. It alsoreceives the delivery and pick-up manifests, resolves any exceptions,manages preferences, and monitors the status of the lease and the lockermodule. It also manages the automated notification sending of messagesto the necessary parties.

In the preferred embodiment, the vendors, the delivery and pickup agentsshould be registered with the system controller. The purpose of theregistration is to uniquely identify a party. In the preferredembodiment, the registration process is conducted via a web site throughthe Internet, though clearly, other modes of communication are clearlypossible. Referring now to FIG. 5A, the registration process begins instep 90 at which a corporate user, i.e., a vendor or delivery/pickupagent, accesses the system controller's web site. In step 91, thecorporate user then chooses the corporate registration option. In step92, the corporate user provides the corporate particulars, which mayinclude a corporation's name, address, contact person, phone number etc.The particulars also include a login name of identifier (login ID) and apassword or identification. Once the requested information is enteredand submitted, the system controller provides the corporate user anidentification number identifying the corporation in step 93. Thecorporate user is now registered. The corporate user's registrationprocess may be used either by the vendor or the delivery/pickup agent.

Although after executing the steps in FIG. 5A the corporate user isregistered, the corporate user may still need to register its deliveryor pickup persons. This is particularly true if the corporate user is adelivery/pickup agent such as global courier company where deliveringgoods is its main function. However, even if the corporate user is avendor such as a multi-national computer manufacturer where its mainfunction is not necessarily delivery, it may still wish to register itsdelivery persons if the corporation offers a delivery service. FIG. 5Billustrates the steps for registering the delivery persons.

Referring to FIG. 5B, in step 94, the registered corporate user loginsat the system controller's web site using its login name and password.If the proper login name and password are entered, the user is givenaccess to various options. In step 95, the corporate user chooses theoption to register its delivery or pickup persons. In step 96, thecorporate user provides the particulars of each of the delivery orpickup persons in the fields provided. The particulars may include name,address, etc. The particulars should also include a login ID and pinnumber or identification code. In step 97, each delivery person may beassigned a registered smart card to be used in conjunction with the pinnumber to access the locker modules. Access codes could be used in placeof the smart card.

A subscription process may optionally be employed after theregistration. The subscription process is basically a scheme by whichthe corporate users choose a particular region of coverage. If thesubscription process is used, the corporate users may only lease thelocker modules, which are located within the subscribed region. Asubscription model may be used based on the extent of the region ofcoverage of the locker modules to be used.

While pre-registration of the customer may be desirable, it is notrequired. In order for the customer to receive their deliveries at thelocker module, they would have to provide at least a notificationidentifier to the vendor or delivery agent making the delivery.

The notification identifier is associated with a customer and issomething personal to the customer. It provides information on how thenotification message of a delivery to be picked up can be sent to him.Any form of notification identifiers is possible as long as that formprovides a unique identification of the customer, sufficient informationto contact the customer and sufficient security for the notificationidentifier to be considered personal to the customer. Some examples ofnotification identifiers are a mobile or pager number, email address, orinstant messaging number.

In the preferred embodiment, the notification identifier is a mobilephone number. When this is provided and a delivery has been made to thecustomer, a SMS notification message will be sent to the mobile phone.There are many advantages to using a notification identifier.Notification identifiers are often something personal and are usedfrequently such as, for example, a mobile phone number or an emailaddress. Hence, the customer is less likely to forget notificationidentifiers. Another advantage of this is that the customer is able toalways provide his latest contact information for the delivery to bedone as he provides his identification identifier only when he wants adelivery to be made to the locker module. Therefore, there is no needfor registration and management of an account.

In the preferred embodiment, the notification identifier is used inconjunction with an identification code that is provided in thenotification message, for the customer to gain access to the locker unitto collect his good. This is more advantageous than using an IC Card andpin to access the locker unit as these cards can be lost or spoilt.Also, with the notification message sent using the notificationidentifier, the customer has no need to memorise his pin number, thuseliminating another problem of having to remember and manage hisidentification code.

The identification code is a unique one-time code that the customer hasto present to the locker module in order to collect his delivery. Thisidentification code is generated by the system controller and is limitedfor each transaction only and cannot be used again for anothertransaction.

The preferred embodiment shall now be described in light of the variousscenarios that can happen during a delivery or pickup.

There are several scenarios where a delivery can be made with thepresent system. In some of the scenarios, the vendor, and delivery agentare registered with the system controller where they provide theirparticulars and register a smart card and a pin number. Alternatively,the system controller could issue a company access code and pin numberto the registered vendor and delivery agent. For the delivery agent, itregisters itself as a company as well as the individual persons who willbe making the delivery. The purpose of registering with the systemcontroller is to provide the system with credentialing andidentification details of the one making the delivery. As for thecustomer, he can choose to be registered with the system controller.However it is not necessary. Instead, he has to provide his notificationidentifier to the vendor or delivery agent before delivery can be done.This notification identifier is associated with the customer and alsoprovides information on how the notification message can be sent to him.For example, the notification identifier can be his mobile or pagernumber, email address, instant messaging number or the like. If thenotification identifier provided is a mobile phone number, an SMSnotification message will be sent to the mobile phone. The advantage isthat the customer is able to always provide his latest contactinformation for the delivery to be done.

In the first delivery scenario, a locker module of the present inventionis located near the customer's home. A customer makes an order to thevendor and request for the delivery of the order to be made to thelocker module, as there will be no one present at home to receive thegood. The customer provides his notification identifier and request forpayment to be made only at the point of collection of his good. Thevendor uses an independent delivery agent, e.g. post office, for thedelivery. The vendor and delivery agent are both registered with thesystem controller. In this case, the delivery party comprises of thevendor and delivery agent, and the receiving party is the customer.

A flow diagram illustrating the general process flow for facilitatingsuch a delivery is shown in FIG. 6A. Here, the vendor makes areservation or leases a locker unit and informs the delivery agent ofthe reservation. During leasing of the locker unit, the vendor providesthe required details of the customer and the delivery agent so that therespective parties can access a leased locker unit. The vendor thennotifies the registered delivery agent to deliver the good to the leasedlocker unit of the specified locker module. The delivery agent thensends a registered delivery person to the site of the locker module. Theregistered delivery person uses a registered smart card with pin toaccess the leased locker unit to drop off the goods into the lockerunit. Alternatively, the delivery person can also access the leasedlocker unit by using the company access code and pin number issued. Inthis case, no smart card is necessary. The system controller notifiesthe customer that the delivery has been made and that he should pick upthe delivered good. Notification is sent using the notificationidentifier provided by the customer. The customer accesses the leasedlocker unit by entering at least an identification code provided in thenotification message.

FIG. 6A provides only an overview of the delivery transaction. Thedetails of each of the steps in FIG. 6A are described as follows.Referring now to FIG. 6A, in step 100, the parties are first registeredwhere the vendor and delivery agent, provide its particulars andregister a smart card and a pin number with the system controller. Thedelivery agent registers itself as a company as well as the individualpersons who will be making the delivery.

In step 102, the registered vendor leases a locker unit of appropriatesize from the locker module located near the customer's home or of thecustomer's choice via the Internet using an their computers as theiruser input interface. During the leasing process, the vendor providesthe required details of the customer, e.g., customer's notificationidentifier, (in this case the mobile phone or pager number), and thedelivery agent so that the respective parties can access the leasedlocker unit. In step 104, the vendor then notifies the registereddelivery agent to deliver the good to the specified locker unit of thespecified locker module. In step 106, the delivery agent sends aregistered delivery person to the site of the locker module, who thenuses a registered smart card to access the specified locker unit to dropoff the good into the locker unit. In step 108, the system controllernotifies the customer via the notification system, e.g. SMS network thatthe delivery has been made and that he should pick up the deliveredgood. In step 110, the customer accesses the locker unit by entering anidentification code and notification identifier, e.g. mobile phonenumber and picks up the delivered good after making the necessarypayment at the locker module.

In the second delivery scenario is the same as in the previous scenarioexcept that the no prior reservation or lease is made on the Internet.Instead, the locker unit is reserved or leased only at the point ofdelivery at the locker module. In this scenario, the vendor does notneed to be registered with the system controller and can appoint adelivery agent who is registered to make the delivery. When the vendorinforms the delivery agent to make a delivery, the vendor provides thedelivery agent the location of the locker module and the customer'snotification identifier. A registered delivery person takes the goods tothe specified locker module and leases a locker unit at the site. Thedelivery person provides the notification identifier to the lockermodule. By sending a notification message, the system controllernotifies the customer that the delivery has been made and that he shouldpick up the delivered good. The customer accesses the locker unit byentering an identification code provided in the notification message. Inthis case, the delivery party is the delivery agent and the receivingparty is the customer.

A variation of this scenario is when the registered delivery personmakes a delivery attempt to the home of the customer but there is no onephysically present at home to receive the good. However, the deliveryperson is able to obtain the customers notification identifier, e.g.mobile phone number. He can choose to make a delivery to the lockermodule directly, thus saving a second trip using the general stepsdescribed above.

FIG. 6B provides an overview of a delivery transaction and details ofeach of the steps in the delivery transaction are provided as follows.Now referring to FIG. 6B, in step 120, the delivery agent registers asmart card and a pin number with the system controller for its deliverypersons. In step 122, the vendor informs the delivery agent to make thedelivery. Here, if the vendor is aware of the present locker system, thevendor provides the delivery agent the notification identifier, e.g.mobile or pager number of the customer and may even specify the locationof the locker module where the delivery needs to be made. In step 124,the delivery agent uses a registered delivery person to make thedelivery. The delivery agent is informed by the vendor of thenotification identifier of the customer and the location of the lockermodule. The delivery person goes directly to the locker module locationand leases a locker at the site using the user input interface providedat the locker module. The delivery person has to provide at least thenotification identifier of the customer.

In step 126, once the delivery is made, the system controller sends anotification message using the identification identifier that wasprovided by the delivery person. For example, if a mobile phone numberwas provided, a SMS message will be sent. In step 128, once the customerreads the notification message, the customer picks up the delivered goodusing an identification code and his notification identifier.

In the third delivery scenario, two parties wish to make a goodstransfer. However, they are both not registered with the systemcontroller. Essentially, there is a just a delivery party of the goodand a receiving party of the good. No prior reservation or registrationis made or is necessary.

The delivery party could be a vendor, a delivery agent or an individualwho wish to make a delivery to an individual or a group (receivingparty) but who has not made any previous registrations with the systemcontroller. The delivery party could also be an individual who wishes tomake a delivery to a receiving party, where the receiving party can beanother individual, vendor or delivery agent. The delivery party couldalso be an individual who wish to make a delivery to another individual(receiving party). An example would be a non-registered laundrydeliveryman who tries to deliver some laundry to a customer. However, asthere is no one physically present at home to take the delivery.Usually, in such a scenario, the deliveryman has to make a secondattempt. However, if he has the customer's notification identifier, e.g.mobile phone number, he can use the locker system to make the delivery.

The non-registered delivery party takes the goods to the specifiedlocker module and leases a locker unit at the site by either making apayment for fixed lease duration or indicating that the receiving partyhas to pay for the lease. The delivery party provides the notificationidentifier of the receiving party to the locker module. By sending anotification message, the system controller notifies the receiving partythat the delivery has been made and that he should pick up the deliveredgood. The receiving party accesses the locker unit by entering anidentification code provided in the notification message and makingpayments for the lease if necessary. In this scenario, the deliveryparty and the receiving party can be the same person, i.e. the deliverycustomer is using the locker module as a temporary storage facility.

A flow diagram illustrating the general process flow for facilitating adelivery for the scenario described above is shown in FIG. 6C. A lockermodule of the present invention is located at a convenient location forboth parties and both parties agree to the good being delivered there bythe delivery party and later to be picked up by the receiving party.

FIG. 6C provides only an overview of a delivery transaction. The detailsof each of the steps of the delivery transaction are described asfollows. Now referring to FIG. 6C, in step 130, the delivery party needsto make a delivery to a receiving party. No prior registration isrequired for both the delivery and receiving parties. The receivingparty must provide the delivery party his notification identifier, e.g.mobile or pager number and specify the location of the locker modulewhere the delivery needs to be made. In step 132, the delivery partygoes directly to the locker module location and leases a locker unit atthat location and makes the delivery.

In step 134, once the delivery is made, the system controller sends anotification message using the identification identifier that wasprovided by the delivery party. For example, if a mobile number wasprovided, a SMS message will be sent. In step 136, once the receivingparty reads the notification message, the receiving party picks up thedelivered good using an identification code and his notificationidentifier at the locker module.

Typically this scenario could also apply in a case where a customerwants to make a return of a good to a vendor who is not registered withthe system. Instead of having to undergo all the steps of registration,the non-registered vendor can just provide the customer his notificationidentifier, e.g. mobile phone number. The customer can then make thedrop off at the chosen locker unit and the system controller will informthe non-registered vendor via his notification identifier of when andwhere he can do his pickup. In this case, the vendor is the receivingparty and the customer making the return is the delivery party. Inanother variation to this, a customer may want to use the locker unit asa temporary storage facility. The customer now plays the role of boththe delivery and receiving party. In all cases, payment can be collectedat the locker module either during delivery or during collection,depending on how a payment scheme is implemented.

There is an added security over other systems in that the identificationcode that is required to access the locker unit after the delivery ismade is only made available to the receiving party through thenotification identifier of the receiving party. The delivery party doesnot know the identification code and has no access to it. Therefore, hecannot access the locker unit after the drop off has been made.

In the fourth delivery scenario, it is a typical delivery scenario wherea customer makes an order to the vendor and request for the delivery ofthe order to be made to the home. There is a locker module of thepresent invention located near the customer's home. However, thecustomer has not requested for the good to be delivered to the lockermodule, and neither has he provided any notification identifier to thedelivery person making the delivery. The assumption for this scenario isthat the delivery agent and associated delivery persons are registered.

When the delivery person makes a delivery attempt, there is no onephysically present at the customers home to receive the good. In thiscase, if the delivery person is able to obtain the customersnotification identifier, e.g. mobile phone number, he can make adelivery to the locker module directly, thus eliminating the need foranother delivery attempt.

However, if no notification details of the customer are available, thedelivery person drops of a delivery advice informing the customer of hisdelivery attempt and informing him that the good can be collected fromthe locker module. At the locker module, the delivery person leases alocker unit of an appropriate size from the locker module by providing aunique delivery identifier (e.g. delivery order number, or registeredarticle number) of the good to be delivered and some customer addressdetails. The delivery advice that is dropped off provides details of howthe customer can collect his delivery from the locker module.Essentially, the customer is required to contact the system controllerand provide his notification identifier and delivery identifier using anautomated notification system (e.g. Interactive Voice Response System ora web based enquiry system). The system controller will send thenotification message to the customer using the notification identifierprovided. By sending a notification message, the system controllernotifies the customer that the delivery has been made and that he shouldpick up the delivered good. The customer then accesses the locker unitby entering an identification code or pin number provided in thenotification message. In this case, the delivery party is the deliveryperson and the receiving party is the customer.

FIG. 6D is a flow diagram illustrating the general process flow forfacilitating a delivery to the customer even when no notificationidentifier of the customer is available. Here, when the delivery personis unable to make a successful home delivery, he drops off a deliveryadvice card at the customer's home and makes a lease of a locker unit atthe locker module to deliver a good. The customer then followsinstructions indicated in the delivery advice to make a collection ofthe good from the locker unit.

FIG. 6D provides only an overview of a delivery transaction. The detailsof each of the steps of the delivery transaction are described below.Referring now to FIG. 6D, in step 150, the delivery agent and itsassociated delivery persons are registered with the system controller.In step 152, the delivery person attempts to make a delivery of a goodto the customer's home. However, the delivery cannot be completed, asthere is no one present to receive the good. Also, he has no contactdetails of the customer and is thus unable to obtain a notificationidentifier of the customer. Instead of having to make a second deliveryattempt, the delivery person drops off a delivery advice card informingthe customer of his delivery attempt and that the customer can pick upthe good from the locker module. In this scenario, the delivery person,in step 154, goes to the locker module and leases a locker unit ofappropriate size to store the good. In leasing the locker unit, thedelivery person provides particulars that include a good identificationnumber (e.g. delivery order number or registered article number) andcustomer address details.

The customer is instructed by the delivery advice to contact the systemcontroller to obtain details of his collection. In this scenario, thecustomer calls an Interactive Voice Response System or logs on to awebsite managed by the system controller and provides his notificationidentifier and delivery identifier. This is done in step 156. The systemcontroller in step 158 sends a notification message to the customer viathe notification identifier. In the preferred embodiment, the customer'smobile phone or pager is used e.g. Short Message Service (SMS) messagethat the delivery has been made and that he should pick up the deliveredgood. In step 160, the customer accesses the locker unit by entering anidentification code and notification identifier, e.g. mobile phonenumber and picks up the delivered good after making payment at thelocker module, if necessary. After collecting his good and closing thedoor, the system controller is notified and the transaction iscompleted.

In the preferred embodiment of this invention, the method offacilitating a delivery and collection of goods where the methodinvolves a customer, a vendor, and a delivery agent, the delivery agenthaving a plurality of delivery persons, the vendor having to deliver agood to the customer using the delivery agent comprises the steps ofproviding a locker module having a plurality of locker units; providinga registration platform for registering the vendor, delivery agent, andat (east one delivery person; allowing a vendor or delivery agent leasea locker unit by providing a set of particulars to the systemcontroller, the particulars including at least a notification identifierof the customer and credentialing information of the delivery person; orallowing a registered delivery person to lease a locker unit by havingthe delivery person provide a set of particulars to the locker module,the particulars including at least a notification identifier of thecustomer; providing the registered delivery person access to a lockerunit when the particulars are provided to the locker module such thatthe good may be placed inside the locker unit; sending a notificationmessage using the notification identifier provided or entered, thenotification message providing at least a notification to pick up thegood, a location of the locker module, and a unique identification code;and allowing the customer access to the locker unit containing the goodwhen the unique identification code is provided to the locker module.Clearly, the delivery party comprises of the vendor, delivery agent andits associated delivery person, while the receiving party is thecustomer.

Further to this, the method of facilitating a delivery of goods wherethe method involves a delivery party to deliver goods to a receivingparty comprises the steps of providing a locker module having aplurality of locker units; allowing the delivery party to lease a lockerunit by having the delivery party provide a set of particulars to thelocker module, the particulars including at least a notificationidentifier of the receiving party; providing the delivery party accessto a locker unit when the particulars are provided to the locker modulesuch that the good may be placed inside the locker unit; sending anotification message using the notification identifier entered, thenotification message providing at least a notification to pick up thegood, a location of the locker module, and a unique identification code;and allowing the receiving party access to the locker unit containingthe good when the unique identification code is provided to the lockermodule. In this case, no registration of both parties is necessary.

The preferred embodiment is extended to include the method offacilitating a delivery and collection of goods where the methodinvolves a customer, and a delivery agent, the delivery agent having aplurality of delivery persons, the delivery agent having to deliver agood to the customer's home using the delivery agent but failing as thecustomer is not at home comprises the steps of providing a locker modulehaving a plurality of locker units; providing a registration platformfor registering the delivery agent, and at least one delivery person;allowing a delivery person to drop of a delivery advice at thecustomer's home and lease a locker unit by providing a set ofparticulars to the system controller, the particulars including at leasta delivery identifier and address particulars of the customer; providingthe registered delivery person access to a locker unit when theparticulars are provided to the locker module such that the good may beplaced inside the locker unit; providing an automated notificationsystem for customers to provide their notification identifier; sending anotification message using the notification identifier provided, thenotification message providing at least a notification to pick up thegood, a location of the locker module, and a unique identification code;and allowing the customer access to the locker unit containing the goodwhen the unique identification code is provided to the locker module.

There are two scenarios where pickup transactions can be made with thepresent system.

In this first pickup scenario, the parties may first be registered whereeach of the parties, the pickup agent and vendor provides hisparticulars and registers with a smart card and a pin number with thesystem controller. Alternatively, the system controller could issue acompany access code and pin number to the registered vendor and pickupagent. The vendor and the pickup agent could both be registered as acompany as well as the pickup persons who will be making the pickup. Thecustomer need not be registered even when he wants to use the service aslong as he is able to provide a notification identifier. When thecustomer wants to make a good return to a registered vendor, he willnotify the vendor with his particulars (including notificationidentifier) and the locker module where he wishes to perform thereturns. The registered vendor leases a looker unit of appropriate sizefrom the locker module of the customer's choice via the systemcontroller's web site. During the leasing process, the vendor providesthe required details of itself and the customer so that the respectiveparties are able to access the leased locker unit. The system controllerthen notifies the customer through a notification message that a lockerunit has been reserved for him. The customer drops off the good in thelocker unit per the system controller's message, using theidentification code provided in the notification message. The systemcontroller then notifies the vendor that the good has been dropped off.The vendor picks up the good using a registered pickup person. Thevendor could also appoint a registered pickup agent and his pickupperson to pick up the good.

A typical pickup scenario such as where a customer wants a Laundromat topickup his laundry to be cleaned can be illustrated by the differentroles that are required in such a situation. In this scenario, thevendor is also the pickup agent, and takes on the role as a leaseholder.The customer is again the end user. The vendor has a direct relationshipwith the system controller as the vendor leases a locker from the systemcontroller. The vendor also has a direct relationship with the customeras the vendor performs a service on the good to be picked up. In thiscase, the delivery party is the customer while the receiving party isthe vendor (who plays the role of both the leaseholder and pickupagent).

A flow diagram illustrating the general process flow for facilitating apickup for the scenario shown is shown in FIG. 7A. This is a scenariowhere a customer wants a vendor to pickup a good such as a laundry or abroken item to be cleaned or repaired. But the vendor operates duringhours when the customer will not be present at home to hand over thegood. A locker module of the present invention is located either nearthe customer's home or at a convenient location. The vendor will besending someone from his company to pickup the good. FIG. 7A providesonly an overview of the pickup transaction; the details of each of thesteps in FIG. 7A shall be provided further below.

Now referring to FIG. 7A, in step 250, the vendor is first registered asa company as well as the individual persons who will be making thepickup with the system controller by providing particulars of thecompany and the pickup persons. The vendor also registers smart cardsand pin numbers for each pickup agent. If pickup agents are used, theyare to be registered with the pickup persons as well. Instead of usingsmart cards, an access code could be issued.

In step 255, the customer requests for a pickup service from theregistered vendor and he leases a locker unit of appropriate size fromthe selected locker module via the Internet. During the leasing process,the vendor provides the required details of itself and the customer sothat the respective parties are able to access the leased locker unit.In the preferred embodiment of the system, the customer's notificationidentifier is required and this could be his mobile phone number. Instep 260, the system controller notifies the customer that a locker unithas been reserved for him. The notification message will include detailsof locker location, locker unit number and an identification code or pinnumber to access the locker unit. Alternatively, or in conjunction, thevendor notifies the customer of the same. In step 265, the customerdrops off the good in the locker unit per the system controller'smessage. In step 270, the system controller notifies the vendor that thegood has been dropped off. This could be in the form of reports orautomated phone calls. Alternatively, or in conjunction, the customernotifies the vendor of the same. In step 275, the vendor picks up thegood using a registered pickup person.

In the second pickup scenario, an enhanced pickup or returns servicecould also be provided for registered vendors. An interface could becreated allowing the customer to directly make the good returns usingthe user input interface at the locker module without the need ofcontacting the registered vendor. This is especially useful for vendorsexpecting large volumes of returns and would like to offer extendedconvenience and operating hours to their customer. Such vendors could beLaundromats, Video Rental Stores, Book Rental Stores or Equipment RentalStores. A locker module of the present invention is located either nearthe customer's home or at a convenient location. This could be at hightraffic areas such as train stations. The locker modules could even belocated outside the vendor's premise, thus offering round the clockreturn facilities. When the returns are done, the vendor will be sendingsomeone from his company to pickup the good. The customer selects thevendor that he wishes to make a good return to at the locker module byselecting the appropriate vendor code, leases a locker unit ofappropriate size from the locker module and drops off the good. Whenthis is done, the system controller will notify the registered vendor ofthe need to collect the returns. The vendor picks up the good using aregistered pickup person or appoints a registered pickup agent to doperform the pickup using the identification code provided in thenotification message. Customers may be required to pay for the servicedepending on the arrangement with the vendors.

A flow diagram illustrating a customized process flow for facilitating apickup is shown in FIG. 7B. FIG. 7B provides only an overview of thepickup transaction; the details of each of the steps in FIG. 7B shall beprovided further below.

Now referring to FIG. 7B, in step 250, the vendor must first beregistered as a company as well as the individual persons who will bemaking the pickup with the system controller by providing particulars ofit and the pickup persons. It also registers smart cards and pin numbersfor each pickup agent. Instead of using smart cards, an access codecould be issued.

In step 300, the registered vendor subscribes for a customized system atthe locker module where the customer can select to directly make a goodreturn to the vendor. Different vendor returns selections are madeavailable at the locker modules. The customer, in step 310, will selectthe appropriate vendor at the locker module and enters his particularsand select appropriate locker unit size. In the preferred embodiment,the customer should also enter his notification information as well asmake a payment (optional—depending on vendor scheme) before he canaccess the locker unit. Once the locker unit door has been closed, thesystem controller is informed of the status of the transaction andnotifies the vendor of the need to perform a pickup in step 320. Thenotification message will provide an identification code that will beused by the pickup persons to unlock the locker unit to pickup goods.The notification message could be in the form or emails, reports,automated phone calls or on the system controller website. The vendorthen arranges for the pickup to be done using his registered pickuppersons in step 330.

Further customization could be done for the vendors by automaticallynotifying their preferred pickup agent to perform the pickups ratherthan picking it up themselves. In this case, the registered pickupagents could even offer a one stop returns service for a number ofvendors, who need not be registered with the system.

In both pickup scenarios, the vendor could also arrange for a registeredpickup agent and their pickup persons to perform the pickup, instead ofdoing it themselves. In all cases, the identification code provided forin the notification message is used to access the locker units to pickup the goods.

In the preferred embodiment of this invention, the method offacilitating a pickup of goods where the method involves a customer, avendor, and a pickup agent, the pickup agent having a plurality ofpickup persons, the vendor having to pickup a good from the customerusing the pickup agent comprises the steps of providing a locker modulehaving a plurality of locker units; providing a registration platformfor registering the vendor, pickup agent, and at least one pickupperson; allowing a vendor or pickup agent lease a locker unit byproviding a set of particulars to the system controller, the particularsincluding at least a notification identifier of the customer andcredentialing information of the pickup person; sending a notificationmessage using the notification identifier provided, the notificationmessage providing at least a notification to drop off good for returns,a location of the locker module, and a unique identification code; andallowing the customer access to the locker unit to drop off the goodwhen the unique identification code is provided to the locker module;providing the registered delivery person access to a locker unit whenhis credentialing particulars are provided to the locker module suchthat the good may be picked up from the locker module.

The preferred embodiment of this invention further includes, the methodof facilitating a pickup of goods where the method involves a customer,a vendor, and a pickup agent, the pickup agent having a plurality ofpickup persons, the vendor having to pickup a good from the customerusing the pickup agent comprises the steps of providing a locker modulehaving a plurality of locker units; providing a registration platformfor registering the vendor, pickup agent, and at least one pickupperson; providing a special interface at the locker module for customerto access to the locker unit to drop off returns; sending a notificationmessage to the vendor/pickup agent, the notification message providingat least a notification to pickup good for returns and location of thelocker module; providing the registered pickup person access to a lockerunit when his credentialing particulars are provided to the lockermodule such that the good may be picked up from the locker module. Inthe preferred embodiment, the credentialing particulars would include aaccess code and unique identification code that will be given to eachvendor/pickup agent for each locker module as this allows thevendor/pickup agent more flexibility of assigning a pickup person topickup the returns without having to register the pickup person. This isgiven in a form of notification message, which could be in the form of areport.

In both pickup scenarios, the customer is the delivery party while thevendor and/or pickup agent is the receiving party. In the secondscenario, the vendor code is also known as the receiving party code.

The leasing process will now be elaborated to explain the preferredembodiment of the invention. Leasing of a locker unit for delivery canbe done from the Internet or at the locker module. The user inputinterface from the Internet could be a computer device connected to theInternet, while the user input interface at the locker could be thecomputer monitor and keypad.

Referring to step 102 in FIG. 6A and step 120 in FIG. 6B, once theparties are registered per the steps shown above, a locker unit may beleased by a corporate user (who could be a vendor or a delivery agent).FIG. 8 illustrates the preferred process for a corporate user to lease alocker unit from the Internet. In step 400, the corporate user obtainsthe login identification number (or “login ID”) of the delivery agent.The delivery person's login identification number need not be known atthis point, but may be entered if it is available. In step 410, thecorporate user accesses the system controller's web site, enters theproper login ID and password, and chooses the option to reserve a lockerunit. In step 420, the corporate user provides the particulars requestedby the system controller. In the preferred embodiment, the particularsare the delivery agent's login ID, the location of the locker module,size of the locker unit needed, the date of the lease, duration of thelease, and the customer's notification identifier, e.g. mobile or pagernumber.

Once all of the information is provided, the system controller providesthe corporate user with a unique transaction number in step 430 andreserves the designated locker unit and the designated locker module atthe designated date. The lease is good for a specified duration.

Now referring to step 104 of FIG. 6A and step 122 of FIG. 6B, the vendornotifies the delivery agent of the delivery. Besides the usualinformation provided to a delivery agent, e.g., company particulars, thevendor provides the unique transaction number obtained in step 430 tothe delivering agent. The vendor may communicate this information in anyway that is convenient to the parties.

Now referring to step 106 of FIG. 6A, using the transaction number, thedelivery agent accesses the vendor's locker reservation request site onthe system controller's web site. From the site, the delivery agent isable to ascertain the both the location and the time of delivery as thetransaction number will allow it to access the lease information. Oncethere, the delivery agent enters the login ID of the delivery person whowill be making the delivery to complete the lease transaction. Thesystem controller sends all necessary lease information to the lockermodule carrying the leased locker unit. The locker module controllerthen uses the information to provide selective access to the leasedlocker unit.

To make the delivery, the designated delivery person takes hisdesignated smart card to the designated locker module site on thedesignated date. Once there, he inserts the card into the slot provided.The locker controller reads the unique serial number of the card andafter conducting a series of checks asks for the delivery person's pinnumber on the monitor. In place of the designated smart card, an accesscode could be used as well. The locker controller opens the leasedlocker unit only if the proper pin number or identification code isentered via the provided keypad.

The preferred embodiment also allows for a lease to be made at thelocker module itself. In this case, only the delivery agent and itsassociated delivery persons need be registered with the systemcontroller. Instead of leasing on the Internet, the delivery agentchooses to only lease the locker at the point of delivery at the lockermodule.

The locker leasing process for the step shown in step 124 of FIG. 6B issomewhat different than that shown in step 102 for FIG. 6A. In step 124,when the delivery person inserts his smart card into the locker module,by reading the serial number of the smart card and matching it againstthe database, the locker controller is aware that no prior lockerreservation has been, and that the delivery agent will be leasing alocker unit. Assuming that the delivery person's smart card has beenproperly registered, the locker module prompts the person to enter hispin number. Only if a proper pin number is entered will the deliveryperson be allowed to make a lease at the locker module. The lockermodule will prompt the delivery person to enter the notificationidentifier, e.g. mobile phone or pager number, of the customer. Once thenumber is entered, the person is prompted to enter the particulars ofthe lease and the delivery, which can include, among others, the size ofthe locker needed, duration of the lease, and the delivery order number(for delivery agent's own records). When all the information is enteredand confirmed, the appropriate locker unit opens. After the deliveryperson places the goods inside the locker unit and properly closes thedoor, the module asks if any additional transactions are needed. Onceconfirmed “no”, the lease transaction ends, and the smart card isreturned back to the delivery person. A pre-made set of selections maybe provided for the location of the locker module and the size of thelocker unit.

The preferred embodiment of the present invention further extends theability to make a lease for delivery of a good to the locker module to auser who is not a corporate user (i.e. non registered vendor or deliveryagent and its delivery persons). Referring to FIG. 6C step 132, thedelivery customer obtains the receiving customer's notificationidentifier and leases a suitable locker unit at the point of delivery atthe locker module. The delivery customer selects the appropriatetransaction at the locker module and is prompted to enter particulars ofthe lease, including the receiving customer's notification identifier,appropriate locker unit size and lease duration. In the preferredembodiment, payment for the lease is to be done by the delivery customerfirst before he is allowed access to the locker unit. However, there isalso a possibility of having the receiving customer pay for the lease atthe point of collecting the delivery.

In the leasing process for the delivery of a good to a customer when nocustomer notification identifier details are available, the registereddelivery person in FIG. 6D step 154 leases a locker unit at the lockermodule by selecting a lease function that will require the deliveryperson to enter particulars of the transaction; including at least thegood identifier, which could be the delivery order number or registeredarticle number, and address details of the customer. To access thisfunction, the delivery person will have to insert his smart card intothe locker module and enter his pin. Only after verification of hisdetails, by reading the serial number of the smart card and matching itagainst the database, will he be allowed to proceed with thetransaction. Once the required details are entered, the delivery personwill be given access to the locker unit to make his delivery. Details ofthis transaction are sent to the system controller.

Now referring to step 108 of FIG. 6A, step 126 of FIG. 6B and step 134of FIG. 6C, once the delivery is made and the leased locker unit's dooris properly closed, the status of the transaction is remotely sent bythe locker controller to the system controller. The system controller isnow aware that the delivery has been made. The system controller thennotifies the customer that the delivery has been made and that the goodis ready to be picked up. The notification message is sent, depending onthe type of notification device the customer has, it could be via an SMSmessage to the mobile phone or pager number provided by the customer andwhich was entered by the vendor during the locker reservation.

Referring to FIG. 6D step 156, the customer has to contact the systemcontroller and provide his notification identifier in order to receivethe notification message. This is for the event that the delivery personhas made a delivery to the locker module without having any notificationdetails of the customer. Upon contacting the system controller, thecustomer is required to provide details of his delivery identifier andnotification identifier. The system controller will check if such adelivery identifier exists in the system. Only if it exists will thenotification message be sent to the customer using the notificationidentifier provided.

The notification message can include, among others, a note that adelivery has been made, the location of the locker module, locker unitnumber, when the lease will expire, an identification code, and atelephone number to call for help (if help is needed).

Now referring to step 110 of FIG. 6A, step 128 of FIG. 6B, step 136 ofFIG. 6C and step 160 of FIG. 6D, when the customer receives the messagethat the delivery has been ready, the customer goes to the locker modulesite. Once at the locker module, the customer enters the identificationcode provided in the notification message. The locker module mayoptionally ask for the customer notification identifier, e.g. mobilephone number, or delivery identifier, e.g. delivery order number foradditional security. When the proper identification code is entered, theleased locker unit opens for the customer to pick up the good. After thecustomer picks up the good and the locker door is properly closed, thestatus is transmitted by the locker controller back to the systemcontroller. The delivery transaction is now completed.

For the delivery transactions to be executed smoothly and safely, thesystem controller in conjunction with the locker module controllerperforms a number of administrative tasks both during and apart from thetransactions, which shall now be described.

The system controller maintains a large database of the registeredusers. The database is well catalogued so that the particulars of theusers can be readily accessed. During the registration process, thesystem controller ensures that no identical login names exist. Also,during the smart card registration process, the system controllerensures that a smart card having a serial number, which already existsin the database, cannot be registered.

When a locker reservation is requested, the system controller checks theintegrity of all of the necessary entered particulars. First, it ensuresthat the corporate user making the reservation is properly registered bymatching the login name and the password with that in the systemcontroller's database. The same is done for the entered delivery agent'sID, and the delivery person's ID. When the locker module and the lockerunit size are specified, the system controller checks against otherreservations to make certain of its availability. If the locker unit isnot available, the corporate user is so notified.

When the corporate user makes a selection, the system controller definesa set of expected actions from the expected parties. So for instance,when a delivery reservation is made (and assuming that the deliveryperson's ID has been properly entered), the first expected action wouldbe defined as the delivery person making the delivery at the designatedlocker module during a period assigned for the lease. Therefore, whenthe correct delivery person slots in his designated smart card at thedesignated locker module, or he keys in his assigned access code, accesswill be given to the reserved locker unit. After the delivery, the nextexpected action is for the designated customer to pick up the good fromthe locker unit. Hence, when the proper identification code is enteredat the designated locker module, access will be given to the reservedlocker unit. If, however, the customer were to attempt to access thelocker unit before the delivery is made, the event would not correspondto the expected action, and therefore, access to the locker unit wouldnot be provided even though the customer entered the correctidentification code.

The system controller keeps track of all transactions and stores thetransaction details in its databases. Some are stored in the database ofthe system controller while some data is stored in the embedded databaseof the locker module controller PC depending on its use. The data storedin the embedded database is periodically backed up to the systemcontroller's database. If at any time, a user wishes to obtain thestatus of a transaction, he may do so by accessing the systemcontroller's web site and choosing the status option. In addition, thesystem controller stores the past transactions for a limited period.Hence, if a delivery agent, for instance, wishes to obtain a deliveryrecord of a particular delivery person, it may do so. The corporate usercan also update any delivery person details at the web site.

The system controller also keeps track of the payments on alease-by-lease basis. A number of payment schemes are possible using thepresent system including deducting payment from the smart card at thelocker module site. In the locker system for leaseholders who areregistered vendors or delivery agents, the system charges a payment onlyto the leaseholder by keeping track of the number of locker reservationsmade and billing the leaseholder on a billing cycle. As fornon-registered vendors, delivery agents or customers who leases thelocker unit at the locker modules, payment is required to be made at thelocker module using a smart card or any other payment devices.

The system controller has a procedure for a number of events, which aredeviant from the norm. For instance, if a delivery person makes a wrongdelivery and needs to access the locker unit again, a recovery procedureis followed where the delivery person or the delivery agent must call aperson at the system controller site to allow the delivery personspecial access to the locker unit. Similar procedure is followed if adelivery person were to place the wrong items in the locker unit duringa delivery transaction. If the expected delivery or pick-up is not madewithin the expected time frame, the leaseholder is contacted to renewthe lease.

It at any point the system controller loses communication with a lockermodule, it determines the source of the problem by checking thecommunication status of the other locker modules. If it is deemed thatthe source of the problem is at a particular locker module, a servicemanis sent to rectify the problem.

The system controller also consists of an Automated Notification MessageSending System (ANMSS) 14 as shown in FIG. 1. The ANMSS serves toautomate the sending of notification message to the relevant parties,informing them of the need to collect a delivery or make a pickup ofgood returns. The key to the ANMMS is the use of a notificationidentifier. The notification identifier provides the ANMMS withsufficient information to send the notification message.

FIG. 9 illustrates how the ANMMS is used to send notification messages.When the vendor, delivery agent or customer registers with the systemcontroller, they will have to provide one or more notificationidentifiers. However, they will have a preferred choice as to whichnotification identifier will be used. As for vendors, delivery agents orcustomers who do not wish to be registered with the system controllerand would still want to make use of the locker modules as a transferfacility, they would have to provide their notification identifiers atthe locker module.

The notification identifier could be a mobile, pager or phone number, anemail address, instant messaging identifier (e.g. ICQ or Yahoo MessagingNumber), a good or article number (e.g. Delivery Advice Number or ParcelIdentifier) or even a physical address. The notification identifier canalso be the login ID of the registered customer.

In the preferred embodiment, the notification identifier is the mobileor pager number of the end user or receiving customer. Hence when theleaseholder accesses the system controller's web site to lease a lockerunit as in FIG. 6A, he must provide the customer's notificationidentifier, which is the mobile or pager number in this case. If thedelivery to be made is as described in FIG. 6B, and FIG. 6C, then thenotification identifier, which is the mobile or pager number in thiscase, must be entered at the locker module. When the delivery iscompleted, the system controller will send a notification message to theend customer using the mobile or pager number provided.

There are cases where the delivery person is not told of the customer'snotification identifier when he attempts to make a delivery to thecustomer's home. A locker of the present invention is located near thecustomer's home and the delivery person wishes to make a delivery thereinstead of attempting a second delivery. This process is described inFIG. 6D.

In the preferred embodiment, the ANMMS automatically process any requestfor notification to be sent out from the system controller. The ANMMSprocesses the notification messages and associated notificationidentifier and sends out the message using the relevant notificationmeans. For example, if the notification identifier provided is a mobilephone number, then the notification message will be sent out via the SMSnetwork. If an email address is provided as a notification identifier,then the notification message is sent via an email. Clearly manyvariations are possible and those listed are for illustrative purposesonly and are not exhaustive.

In the preferred embodiment, the ANMMS also provides the InteractiveVoice Response System for the process as described in FIG. 6D, so thatcustomers can interact with it to obtain their notification messages.The ANMMS also provides reminder notification messages for customers tomake their collections and is able to also send consolidated reports ofdeliveries or pickups that needs to be done by the delivery/pickupagents.

The present invention may be embodied in other specific forms withoutdeparting from the spirit or essential characteristics thereof. Thepresently disclosed embodiment is, therefore, to be considered in allrespects as illustrative and not restrictive, the scope of the inventionbeing indicated by the appended claims and all changes, which comewithin the meaning and range of equivalency of the claims, are,therefore, to be embraced therein.

1. A method for facilitating transfer of goods between a delivery partyand a receiving party in a locker system comprising at least one lockermodule having at least one locker unit, said method comprising the stepsof: registering, by said delivery party, to provide information on saiddelivery party for storing in a database associated with said lockersystem; providing, by said delivery party to said receiving party, atleast one delivery identifier associated with a delivery attempt;receiving, by at least one controller of said locker system, at leastone user input provided by said delivery party and associated with saidreceiving party, said at least one user input being associated with saidgoods and said receiving party, and including said at least one deliveryidentifier; processing, by said at least one controller, said at leastone user input to allow said delivery party to unlock and to depositsaid goods into a locker unit of said at least one locker unit;providing, by said receiving party to said at one controller, at leastone notification identifier based upon said at least one deliveryidentifier, and generating, by said at least one controller and basedupon said at least one user input, at least one notification message tosaid receiving party, said at least one notification message having anidentification code for unlocking said locker unit.
 2. The method ofclaim 1, wherein said method further comprises the step of unlocking, bysaid at least one controller, said locker unit when said identificationcode is provided by said receiving party to collect said goods.
 3. Themethod of claim 1, wherein said providing step comprises the step ofrelaying said at least one user input to said at least one controller,said at least one controller being a locker controller associated withsaid at least one locker module and having a computer monitor and akeypad.
 4. The method of claim 1, wherein said providing step comprisesthe step of relaying said at least one user input to said at least onecontroller, said at least one controller being a system controllerconnected to a network.
 5. The method of claim 1, wherein said methodfurther comprises the step of transmitting said at least onenotification message to said receiving party using said at least onenotification identifier when said goods is deposited into said lockerunit by said delivery party.
 6. A method for facilitating transfer ofgoods between a delivery party and a receiving party in a locker systemcomprising at least one locker module having at least one locker unit,said at least one locker unit being unlockable by said delivery party byproviding one of an access code and a payment thereto, said methodcomprising the steps of: providing, by said receiving party to saiddelivery party, at least one user input having at least one notificationidentifier associated with the receiving party; receiving, by at leastone controller of said locker system, said at least one user input fromsaid delivery party; processing, by said at least one controller, saidat least one user input and an indication from said delivery party toallow said delivery party to unlock a locker unit of said at least onelocker unit to deposit goods therein, said indication being associatedwith said payment for unlocking said locker unit, said indicationincluding one of a first payment mode in which the delivery patty makesthe payment, and a second payment mode in which the receiving partymakes the payment; and generating, by said at least one controller andbased upon said at least one user input, at least one notificationmessage to said receiving party, said at least one notification messagehaving an identification code for unlocking said locker unit; whereinwhen said access code is unavailable to said delivery party, said atleast one controller allows said delivery party to unlock said lockerunit after processing said indication.
 7. The method of claim 6, wheresaid receiving step is further adapted to allow payment to deposit saidgoods by said delivery party in said locker unit.
 8. The method of claim5, wherein said method further comprises the step of processing by saidat least one controller to unlock said locker unit when saididentification code is provided by said receiving party to collect saidgoods.
 9. The method of claim 8 wherein said method is further adaptedto allow payment by said receiving party to collect said goods.
 10. Themethod of claim 6, wherein said receiving step comprises the step ofproviding said at least one user input via a user input interface. 11.The method of claim 10, wherein said providing step comprises the stepof relaying said at least one user input to said at least onecontroller, said at least one controller being a locker controllerassociated with said at least one locker module and having a computermonitor and keypad.
 12. The method of claim 11, wherein said relayingstep comprises the step of relaying said at least one user input havingat least one notification identifier associated with said receivingparty.
 13. The method of claim 11, wherein said method further comprisesthe step of transmitting said at least notification message to saidreceiving party using said at least one notification identifier whensaid goods is deposited into said locker unit by said delivery party.14. A method for facilitating transfer of goods between a delivery partyand a receiving party in a locker system comprising at least one lockermodule having at least one locker unit, said method comprising the stepsof: registering, by said receiving party, to provide information indatabase associated with said locker system; receiving, by at least onecontroller of said locker system, at least one user input provided bysaid receiving party, said at least one user input being associated withsaid delivery party; and generating, by said at least one controller andbased upon said at least one user input at least one notificationmessage to said delivery party, said at least one notification messagehaving an identification code for unlocking a locker unit of said atleast one locker unit; wherein said receiving step comprises the step ofproviding said at least one user input via a user input interface, saidat least one user input having at least one notification identifierassociated with said delivery party.
 15. The method of claim 14, whereinsaid providing step comprises the step of relaying said at least oneuser input to said at least one controller, said at least one controllerbeing a system controller connected to a network.
 16. The method ofclaim 14, wherein said method further comprises the step of transmittingsaid at least one notification message to said delivery party using saidat least one notification identifier.
 17. The method of claim 14,wherein said method further comprises the step of unlocking, by at leastone controller, said locker unit when said identification code isprovided by said delivery party to drop off said goods.
 18. A method forfacilitating transfer of goods between a delivery party and a receivingparty in a locker system comprising at least one locker module having atleast one locker unit, said method comprising the steps of: registering,by said receiving party, to provide information on said receiving partyfor storing in a database associated with said locker system; receiving,by at least one controller of said locker system, at least one userinput provided by said delivery party, said at least one user inputhaving at least one notification identifier associated with saidreceiving party processing by said at least one controller, said atleast one user input to allow said delivery party to unlock and todeposit said goods into a locker unit of said at least one locker unit;and generating, by said at least one controller and based upon said atleast one user input, at least one notification message to saidreceiving party, said at least one notification message having anidentification code for unlocking said locker unit to retrieve saidgoods.
 19. The method of claim 18, wherein said processing step isfurther adapted to allow payment to deposit said goods in said lockerunit by said delivery party.
 20. The method of claim 18, wherein saidprocessing step comprises the step of relaying said at least one userinput to said at least one controller, said at least one controllerbeing a locker controller associated with said at least one lockermodule and having a computer monitor and a keypad.
 21. The method ofclaim 18, wherein said method further comprises the step of transmittingsaid at least one notification message to said receiving party when saidgoods is deposited into said locker unit by said delivery party.
 22. Themethod of claim 18, wherein said method further comprises the step ofunlocking said locker unit when said identification code is provided bysaid receiving party to collect said goods.